Form Timeouts
When you open a form in a web browser, depending on how long it takes you to complete the form, or if the form is left inactive for a prolonged period, you may encounter a form 'timeout'. Two different types of timeouts can occur - both of which are server-related.
A timeout is the length of time after which the connection between the form and the server will expire, resulting in the form no longer being able to send data to the server and vice versa. Unless the connection is re-established by starting a new form session, you won't be able to complete the form, and any data already entered on it could potentially be lost.
One of the timeouts is related to IIS, where, as a web server running Digitise Forms, IIS allows an 'Idle' timeout period to be specified in order to minimise unnecessary open connections. This is configured within IIS itself. See the Setting an Idle timeout period in IIS and What happens when you reach the end of an IIS session drop-downs at the end of this topic for more information.
- An additional refresh/recycle period can also be configured within IIS, which is also discussed in the IIS drop-downs at the bottom of this topic. The refresh/recycle period is the point at which IIS will close and then re-open without having an impact on any opened forms.
The second timeout is imposed by the Digitise Form Server and is related to the length of a form session - the period during which the form can communicate with Form Server. This second timeout can be set within the form's configuration database, or within Form Manager, or Form Studio. See the Setting a Form Server session timeout in Form Studio and Options available when you reach the end of a Form Server session drop-downs at the end of this topic for more information. Also see the Configuration Settings topic's Security drop-down for information on how to set a session timeout within Form Manager.
- A 'session' is the term used to describe a specified period of communication between two or more devices or 'ends', e.g., computers, automated systems, or live active users. The session starts at a certain point in time, and finishes some time later. If the timeout for a session is reached and the session expires, the connection between the devices or ends will terminate and a new connection will need to be opened so that a new session can be started. For an opened form, where a session ends due to a Form Server timeout, a new session will need to be created in order for the form to be completed. For an IIS-related Idle period timeout, a new session will start automatically when the user returns to the form and tries to enter or select data following a period of inactivity. See the drop-downs, below, for more information.
Applying a server timeout to your form can help to:
- Maintain efficiency. When a connection between the form and the server is left open for extended periods, this can result in an unnecessary drain on the server's resources. Each open connection takes up memory and other system resources, and if too many connections remain open, this can lead to resource exhaustion, affecting the server's performance.
- Maintain server security. A long-term open connection between the server and the form presents a potential security risk as it could be used to maliciously send large amounts of data to the server, or to launch various attacks. Some of the more common types of attack associated with open connections are described in the following table:
- Prevent locks on database records, which could impact on the ability of other users to access the same data.
- Reduce the number of long-running transactions. Leaving a connection open for a long period can lead to long-running transactions which could span multiple database accesses, making it harder to manage consistency and concurrency.
- Alleviate port exposure. Open connections often use specific ports, and leaving these open without proper security measures can expose the server to external threats.
| Type of Attack | Description |
| Brute Force Attack | If the connection remains open, attackers can repeatedly attempt to guess credentials or exploit vulnerabilities. |
| Credential Stuffing | Attackers can use known credentials (from data breaches) to gain unauthorised access. |
| Session Hijacking | An open connection may allow attackers to hijack an existing session and gain unauthorised access to sensitive data. |
| Denial-of-Service (DoS) Attack | Attackers can flood the server with open connections, overwhelming its capacity. |
While keeping connections open for longer periods can improve performance in certain scenarios - for example, where the form is especially long and you need more time to complete it without having to repeatedly re-start your session - it is essential to balance efficiency with security. Proper connection management, coupled with session timeouts, are crucial for preventing many of the above risks.
Setting an Idle timeout period in IIS
To set an Idle timeout for IIS, launch IIS Manager. When IIS Manager opens, click the Application Pools tree item in the left-hand Connections pane. This will populate the central portion of the IIS Manager window with a list of existing Application Pools. Locate the Application Pool running the form that you want to set a timeout for from within the list, then click the name of the Application Pool to select it.
Within the Actions pane at the right-hand side of the IIS Manager main window, click on Advanced Settings. An Advanced Settings dialog box will then appear:
Within the Advanced Settings dialog box, scroll down to and expand the Process Model section, which contains the Idle Time-out (minutes) property. The Idle Time-out (minutes) property has a default of 20 minutes, which means that when a 20-minute period of inactivity has been detected across the entire Application Pool, the Pool will shut down and the current session will end. The Application Pool won't then restart until activity is detected in one of the forms contained within the Pool. If the Application Pool contains only one form, if the form is left open, the 20-minute idle period will commence when the user stops entering or selecting data. If the Application Pool contains more than one form, all forms within the Pool need to be inactive before the idle countdown can begin. Enter a new value for the Idle timeout period, then click OK. For an overview of Application Pools and the options available within the Actions pane, click on the following link, which will take you to Microsoft's online learning Application Pools page:
You can also set a time period for when the Application Pool will perform a scheduled refresh/recycle, which will happen regardless of activity or inactivity across the entire Pool. This has a default of 1740 minutes (29 hours). To edit the scheduled recycle period, select the name of the Application Pool as described above, then from within the Actions pane, click Recycling. This will open up a Recycling Settings dialog box, within which the first of its two configuration screens (labelled as Recycling Conditions, as shown below), will be displayed:
The Regular time intervals (in minutes) property specifies the number of minutes after which the Application Pool will automatically shut down and then restart in order to perform a refresh/recycle. To change this period, enter a new minutes value, then click Next. This will take you to the second of the Recycling Settings configuration screens (labelled as Recycling Events to Log). At the bottom of this second screen, click Finish to save the new Recycling period and to close the dialog box.
You can also change the Recycling period by clicking on the Application Pool name to select it, then from within the Actions pane, click on Advanced Settings. When the Advanced Settings dialog box opens, scroll down to and expand the Recycling section, which is where the Regular Time Interval (minutes) property can be found:
Enter a new value for the Regular Time Interval (minutes) property, then click OK.
What happens when you reach the end of an IIS session
For the IIS-related Idle timeout, you won't receive a message informing you that the current session has ended like you do with a Form Server-related timeout (see below). IIS will simply restart the session when you return to the form after a period of inactivity and try to enter or select data. There will be a delay of a few seconds before you can continue completing the form while IIS restarts and a new session gets underway.
For the Recycling timeout, there will be no noticeable delay when the recycle/refresh occurs. The form will switch seamlessly between the end of the old recycle period and the start of the new one, if the recycle should occur while a form is being completed.
Setting a Form Server session timeout in Form Studio
The form timeout period is controlled by the Maximum Session Length (minutes) property. This is one of the properties included within the Security Category of the form's Profile Settings.
The Maximum Session Length (minutes) property sets a limit on the length of time, in minutes, Datasource actions can be performed after a form has been loaded. The specified session length will commence once a form has been opened, and will continue to count down irrespective of whether the form is being completed or has been left idle. A connection between the form and Form Server will stay open for the duration of this period. The default setting is 60 minutes which means that if a user loads a form and keeps it loaded, after 60 minutes, Datasource actions such as reading data in or submitting the form will cease to work, unless and until the form is refreshed and the session is reset.
To set a different Maximum Session Length, locate the Security Category within the form's Profile Settings. The Maximum Session Length (minutes) property will be listed beneath the Security heading, as shown in the following image:
Replace the default value of 60 minutes with the new value, then publish your form. When the form has been published, the value contained within the Maximum Session Length (minutes) property will then be applied. See below for details of what options are available to you when the end of a Form Server session is reached.
Options available when you reach the end of a Form Server session
Once the end of the session period which has been set within the Maximum Session Length (minutes) property has been reached, the following message will be displayed:
After the message appears, you can either click OK to refresh the form and to reset the session timeout, or click Cancel to dismiss the message without refreshing the form and resetting the session. If you click OK, data already entered on the form is retained - except for the File Upload and Email Text Box Elements - and you can continue to add data to the form and submit it when completed. When the form's session is reset, you will be returned to the point in the form that you were at when the timeout occurred, unless your form contains either a File Upload Element or an Email Text Box Element - see the following Note.
- If your form contains either a File Upload Element or an Email Text Box Element, if you click OK to start a new form session, you will be returned to the page in your form that contains the first occurrence of either of these two Elements. You will then have to re-select a file to upload, or re-enter an email address. Once this has been done, you can then navigate through the remaining pages of your form where data that has already been entered or selected for other Elements will have been retained. If your form contains additional File Upload or Email Text Box Elements, you will have to re-select a file or re-enter an email address for each of them.
If you click Cancel, the form remains displayed and you can still enter data, but if you try to submit the form you will receive a 401 console error. If you click Cancel, after 30 seconds, the session expired message will reappear and you will then have the opportunity to restart the form and continue completing it, or you can cancel the form once again. After cancelling, you can close the browser tab or window to dismiss the form and lose any added data.
Guidance on setting timeout periods
When you're deciding what timeout values to apply to a form, a number of factors ought to be considered, including:
- How many pages does the form contain?
- How many Elements within the form require data to be entered or selected?
- Typically, how long might it take the average user to complete the form?
- How much of an inconvenience would it be if the form session was set to a shorter time period and had to be reset several times while a form was being completed?
- Would a longer form session be preferred, minimising the number of resets that would need to take place?
- Form timeouts should be set to a period long enough to allow a user to comfortably complete the form, and with as little interruption as possible. The timeout periods shouldn't, however, be set so long that a form could potentially be left idle for a long time without the session ending. We purposefully haven't provided specific durations that should be applied to timeouts within this topic as these are highly subjective and should be based on the length of the form, and what general time or other constraints exist within your own organisation.
General guidance on setting a timeout period for each of the timeout types is provided below.
Form Server timeout period
Ideally, the form session should be long enough to enable a user to fully complete the form without having to continually dismiss the message that appears when the session has timed out. While data that has already been entered on the form should be retained each time a new form session is initiated (apart from the File Upload and Email Text Box Elements), limiting the amount of times that a session needs to be refreshed while a form is being completed will minimise the risk of potential data loss. It will also help to lessen the intrusive impact that the repeated appearance of the end-of-session message may have.
Running a form several times and, where possible, getting different users to enter/select the required data would give a good indication as to the average time that it takes to complete the form. The Form Server timeout period can then be set, based on this initial evaluation.
A Form Server session length which is longer than the default may need to be chosen where it is anticipated that the form will take more than 60 minutes to complete due to the amount of data that needs to be entered or selected. The duration of the timeout shouldn't, however, be set to a period significantly longer than the average time that it takes to complete the form, and we would, in most cases, advise against doing this.
Conversely, you may decide to reduce the session length where the form is fairly small and could easily be completed in under 60 minutes.
IIS-related Idle timeout period
For an IIS-related Idle timeout, the Application Pool's session will terminate after the default 20-minute period of inactivity has been detected across the entire Pool. This will result in a delay of a few seconds while a new Application Pool session is started when the form is reactivated. During this slight delay, data can't be entered or selected on the form.
When the new Application Pool session begins, all of the data that has already been entered or selected on the form will be retained and the remainder of the form's Elements can then be completed.
The fact that no message appears when an IIS session has timed out makes this type of timeout less impactful, but the amount of time that opened forms contained within the Application Pool can be left inactive without the session ending should still be a consideration.